It is well known in the prior art for a business to use in its normal every day activities, computers that are programmed with software customized for the business. For example, a university (such as Stanford University in Palo Alto, Calif., USA) may maintain a database of information on (1) students and (2) employees by use of “Campus Solutions” software available from Oracle Corporation, Redwood Shores, California, USA. Such software implements logic and holds data that is specific to the business (such as a university), and hence the software is commonly known as an application program (as opposed to other software, such as an operating system). A business may perform different business functions using different application programs (also referred to as simply “applications”) which may need to exchange data with one another. For example, a student's name and address information that is currently held within the “Campus Solutions” application by PEOPLESOFT may need to be transferred to a customer-relationship-management (CRM) application, e.g. if an alumnus student is to be sent a letter to solicit a donation for the university.
Such information transfer is typically implemented by use of additional software that is manually prepared in certain prior art technologies, as a rigid setup of point-to-point integrations between individual applications. Such additional software (hereinafter “point-to-point integration software”) provides no flexibility or guidance as to how to develop, deploy and maintain such integrations in a dynamic ever changing market. Each point-to-point integration software was therefore costly to develop and even costlier to maintain ongoing as changes were required. Software engineers who developed a typical integration between two specific applications had to each time reinvent the wheel in dealing with many low level request/response cycle plumbing concerns which may be common to multiple integrations. A software engineer was typically given no guidance as to (1) how to approach integration development or (2) what preexisting point-to-point integration software would be most appropriate to use as a starting point for a new integration. Moreover, a user interface to manage point-to-point integration software was static and allowed very little dynamic changes to the online system. With a strong industry trend towards being able to deploy applications as ‘packs’, which are solely integration based in nature, there was no facility to manage the licensing and activation of individually licensable integration software. In an IT world moving away from rigid and fragile point-to-point integrations and towards a dynamic and flexible service oriented deployment platform, a need was identified for more flexible integration.
Information that is held within one application is typically transferred by an integration tool to another application in the form of one or more messages, which are published, for example in XML. One example of an integration tool for PEOPLESOFT applications is called “Integration Broker” which was introduced in a software suite called “PeopleTools 8.4” originally published by PeopleSoft, Inc. which software is now available from Oracle Corporation of Redwood Shores, California, USA. PEOPLESOFT Integration Broker supports synchronous messaging wherein the system expects a response before continuing further processing. PEOPLESOFT Integration Broker also supports asynchronous messaging wherein the system continues processing without waiting for a response. Asynchronous messaging allows a large volume of data to be published, as there is no need to wait for a response. Real-time integration uses synchronous messaging and component interfaces.
Other such integration tools, for an XML message exchange between applications, are well documented in the prior art, including, for example, US Patent Application Publications 20050096932, 20050171980 and 20050038779 owned by Computer Associates International, Inc. These three publications are incorporated by reference herein in their entirety as background. These three publications appear to describe software, called “publisher” which provides functionality to filter the information to be published in an XML message to a target application. See, for example, paragraph [0033] in US Patent Application Publications 20050096932.
An XML message that is published by a PEOPLESOFT application typically contains PSCAMA. PSCAMA is an acronym for PEOPLESOFT Common Application Message Attributes, which is a record that PEOPLESOFT applications add to a message structure, during information processing. The above-identified three publications by Computer Associates International, Inc. appear to describe the use of a filtering code in an audit action field (AUDIT_ACTN) of PSCAMA to filter data records in an XML message. Also, these three publications describe use of a sample XSL program to serve as a starting point for a customer, e.g. administrator, to develop custom XSL programs. See, for example, paragraphs [0043]-[0046] in US Patent Application Publications 20050096932.
In the above-described three publications by Computer Associates International, Inc., a feature called “effective dating” is apparently not used by their target application. Effective dating is a feature of PEOPLESOFT applications which provide the ability for a user to record certain information with a special property or attribute called an “Effective Date” (abbreviated EFFDT). Such information can be either in effect currently, or planned to become effective in future, depending on whether the effective date is before or after a current date in the computer. Hence, PEOPLESOFT applications typically produce an XML message containing effective-dated items (that is, a field with the name “EFFDT” and a value of a date by specifying a day of a month in a year). The inventor of the current application notes that the above-noted three publications appear to not disclose how to publish data that has a future effective date.